Different strategies exist for enabling an application module to interact with a user-owned resource. As used herein, a user-owned resource refers to any functionality, control setting, or data associated with a user who interacts with a user device. For example, one type of user-owned resource may correspond to a camera resource that is provided by the user device. Another type of user-owned resource may correspond to data items (such as a documents, images, audio files, etc.) associated with a particular application module.
On one extreme of the design spectrum, an access strategy may treat all user-owned resources as global resources. This permits any application module that is installed on the user device to access any user-owned resource without restriction. A traditional desktop environment that runs on a personal computer uses this type of an access strategy. For instance, an application module that runs using the desktop system can generally access any of the resources provided by the personal computer by virtue of the fact that the user has permitted the application module to be installed on the personal computer. On the opposite extreme of the design spectrum, an access strategy may treat each application module as an isolated principal that has no access to any user-owned resource under any circumstance. Some types of traditional browser systems use this type of an access strategy or a variation of this type of access strategy. For instance, a web application module that runs using this type of browsing system is generally not allowed to access the user-owned resources installed on the computer device which runs the browsing system.
The first-mentioned access strategy is not optimal because an application module may represent a malicious entity which can access and utilize the user's resources in undesirable ways. The second access strategy is not optimal because an application module may have a legitimate need to access a user-owned resource. Preventing the application module from accessing a resource in this circumstance therefore reduces the utility of the application module, or may force the application module to rely on less efficient work-around solutions to access the user-owned resource. For example, a browser system may rely on a browser add-on to interact with a user-owned resource. But many browser add-ons enjoy overly broad access rights with respect to certain user-owned resources, and thereby may subject the user to undue security risks.
To address the above shortcomings, the industry has proposed various intermediate access strategies. In one case, an access strategy may treat the application modules as isolated entities. When an application requires access to a user-owned resource, the access strategy can display a prompt to the user, asking the user for permission to access to the user-owned resource. This strategy is not optimal, however, because the user may perceive the prompts as bothersome. In another case, an access strategy may provide a manifest which describes the access rights conferred to an application module. Upon installing an application module, the access strategy may ask the user to accept or decline the permission rights described in the manifest. This access strategy, however, is also not optimal because a user may not readily understand the nature of the rights described in the manifest. Further, the manifest may grant the application module overly broad access rights.
The above-noted potential shortcomings are set forth by way of illustration, not limitation. Known access strategies may suffer from additional potential drawbacks.